In an agile development team, there is a phenomenon that has existed for a long time: Procrastination. Developers or team members stay idle in the early stages of development, and cannot complete the work in the later stage.
Scrum Master Lisa found that, in a 5-person development team, the user stories are divided into 4. Each development completes a user story, which leads to all of them being delivered together in the later stage.
Moreover, the developer basically does not spend much time writing acceptance criteria before receiving testable user stories, and the acceptance criteria are not written in enough detail, and it only highlightes modules and functions that should be tested.
If you encounter this situation, what would you do?
The story card of the PO may be too large. It should be divided by function, written according to customer value, and divided into multiple stories.
Developers and testers are both members of an agile team. The relationship between the two should be equal.
The developer and tester should participate in the review together, and after reaching a consensus, start the work, and lastly, leave some time for testing.
Analyze the problem first:
Ideas to solve:
This situation should be the current status of development and testing. When there is no automated testing or when testers can only do functional verification testing, then testing can only be performed after development is complete.
First of all, there is a problem in the statement itself: “ the tester can’t complete the testing”. Because in Scrum, we emphasize the team itself. So, if the testing cannot be completed, it is not the tester but rather the team that failed to deliver on time. From the team's point of view, it is everyone's responsibility to finish it. The blame should not fall solely on the tester.
What if the test cannot be delivered at the end?
Through our analysis, we find that the original test is too heavy in the early and end stage of the development work. What's the reason?
To sum up, we would like to emphasize that it is the responsibility of the team. When we raise this problem in the retrospective meeting we should think of a solution together. These suggestions should be raised by the Scrum Master for the team to discuss together, it is not for the Scrum Master to instruct the team to do and follow.